Java Development for Mobile Phones

Part 3

A. Exploring the File Connection Optional API

A lot of mobile phones these days support the optional File Connection API. The API allows Java ME programs to write data into files on the phone file system. The API is part of the JSR 75 that also includes the Personal Information Management (PIM) API, which provides access to the phone contacts.

In contrast to the RMS system, which organises data into records, the File Connection API provides streams of bytes for writing and reading data from files. Unfortunately for processing text files, Java ME does not support the commonly used BufferedReader and PrintWriter for lines of text. It does however support the Reader and Writer filters that allow character based processing of text files.

You can find a lot of useful material about the API, including code examples, at File Connection API and File Connection Example .

Task 1

The aim of this task is to redevelop the Java ME application that you developed for Task 1 of Part B last week, but instead of using an RMS store use a file instead.

Task 2

The aim of this task is to redevelop the application with complex UI behaviour using an RMS store that you developed in Task 2 of Part B last week.

B. Exploring the Bluetooth API

Bluetooth is wireless networking technology primarily for short-range communication (a few meters). For a mobile phone to support the Bluetooth API (JSR82) it must be Bluetooth-enabled, i.e. include the necessary hardware and networking stack. If the device is Bluetooth- and Java-enabled, it is required to support the Java Me Bluetooth API. Most modern mobile phones are Bluetooth-enabled.

You can find a lot of useful material about the API, including code examples, at JSR 82.

Note that the Java ME platform SDK 3.0 includes an interesting Bluetooth demo application that allows a client device to retrieve images from a Bluetooth Image Server. The demo is developed such that both the client and the server code is the same and the user selects at the start whether a device will play the role of a server or a client. Unfortunately, although Java ME supports threads it does not support the advanced features available in the standard edition, i.e. the concurrent package including the executor framework.

In general, it is a good idea to handle communication connections in separate threads, i.e. not the main thread of the application. This way the application would not completely freeze if there are any communication problems, and you can still cancel the connection.

Note that as Bluetooth applications involve communication between different devices, in order to test any Bluetooth application you need to an emulator for each communication party. This fairly straightforward with the emulator of the Java ME platform 3.0 SDK, as long as use a different platform configuration for each party. Behind the scenes each emulator is using communication ports on the machine it is running to receive messages, so it is important that the different instances of the emulator utilise different communication ports. Some device manufacturers provide specialised tools that need to be used to allow communication between different emulator instances. For example, Nokia provides the Nokia Connectivity Framework.

Task 1

Create a simple Bluetooth Hello, World application. The application will consist of two parts, one playing the role of the server and one the role of the client. If you want you can fall the same approach as the Java ME 3.0 SDK Bluetooth demo were the two parts (server and client) are the same application and at start up you choose whether the device plays the role of the server or the client.

The idea is that the server searches for Bluetooth devices and when it find one running the service you developed it sets up a connection with it and send a “Hello World” message. When the client receives the message is it just prints on the screen and a sends back a “Hello World too” message. After this exchange the connection is closed.

Task 2

Develop a more elaborate application that utilises all the features we have examined. For example, it uses an adaptive interface to present data to the user, it persists data in an RMS store or file, and uses Bluetooth to exchange data with clients thus affecting their interface.

C. Exploring XML support

XML is often used for data exchange as it is a self-describing data format. Typically an XML Schema would describe the structure of XML documents allow some level of interoperability between applications. XML parsers can be used to process XML documents. There two models for parsing XML: DOM and SAX. The former views documents as objects and provides methods from extracting their contents, while the later is event driven calling callback methods whenever elements are encountered.

For a mobile device to support full XML processing it must support the Java ME API XML API for Java (JSR 280). This API support both types of XML parsing (DOM and SAX).

You can find information about the API at JSR 280.

Older mobile devices that do not support the XML API for Java, provide limited XML support through Java ME Web Services (JSR 172). This supports only SAX parsing of XML documents.

You can find information about the Web Services API at JSR 172.

Task 1

This task builds on Task 1 of part B above. Extend the application to use Bluetooth to exchange XML documents instead of a simple “Hello World” message. For example, you can create an XML file that contains the following: device name, user name, greeting message, and then using Bluetooth pass it on to another device, which in turn will parse it, extract the relevant data, show then on the screen, followed by the sending of its own XML document that follows the same format.

Task 2

This task builds on Task 2 of part B above. Develop a version of the application above, where data are exchanged using XML documents.